…realized @path params (Azure#4684)

The "Run unit tests" job failed because the `@override`
`@path`-preservation check (added in Azure#4644) reported
`override-parameters-mismatch` on the `typespec-ts`
`overrideReservedkeywords.md` scenario, even though the override is
valid.

## Root cause
- The check used `isPathParam`, which only inspects the `@path`
decorator on the type graph.
- In the failing ARM operation, the `name` property inherits
`@path`/`@key` from `SubscriptionActionScope` and is collapsed with the
body `name` by `collectParams`, so it *looks* like a path parameter.
- The resolved route
(`/subscriptions/{subscriptionId}/.../checknameavailability`) has no
`{name}` segment — `name` is a body property — so requiring the override
to keep it as `@path` is a false positive that affects ARM overrides
broadly.

## Changes
- **`$override` (`decorators.ts`)**: resolve the operation's real HTTP
route via `getHttpOperation` and build the set of parameters *realized*
as path params. The `@path`-preservation check now uses this set instead
of the raw decorator, falling back to `isPathParam` when no HTTP route
can be resolved (e.g. non-HTTP operations).
- **`getRealizedPathParamNames` helper**: returns realized path-param
names, or `undefined` on failure.
- **Tests**: added a regression case asserting no mismatch is reported
when a `@path`-decorated parameter is not realized in the route.
- **Changeset** added.

```ts
const realizedPathParamNames = getRealizedPathParamNames(context.program, original);
const originalIsRealizedPathParam = realizedPathParamNames
  ? realizedPathParamNames.has(originalParam.name)
  : isPathParam(context.program, originalParam);
```

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: xirzec <639216+xirzec@users.noreply.github.com>

## Problem
The `@override` `@path`-preservation check (added in Azure#4644, reworked in
Azure#4693) produced false `override-parameters-mismatch` diagnostics on real
ARM specs. Three distinct issues:

1. **Azure#4693** switched parameter matching to name-based, which
over-relaxed the check.
2. **Azure#4644** compared parameters by sorted **position**; when an
override adds/reorders parameters the index misaligns, flagging params
that already carry `@path` (e.g. botservice `channelName`).
3. Determining "is a path parameter" from the `@path` decorator in the
**type graph** (`isPathParam`) is unreliable: a parameter can carry
`@path` without being part of the realized route (e.g. an ARM key
surfaced by a templated `ArmProviderActionSync`, as in cognitiveservices
`calculateModelCapacity`), and conversely a `@path` nested inside a
plain model or `@bodyRoot` IS realized.

## Fix
- **Revert Azure#4693** to restore positional structural comparison of the
parameter lists.
- **Resolve the original operation's realized HTTP route**
(`getHttpOperation`) to get its actual path parameters — the ground
truth that handles both phantom `@path` (orphaned, not in route → not
enforced) and nested `@path` (in route → enforced).
- **Match the corresponding override parameter by name** (not position)
and require it to be a path parameter (`isPathParam`). This removes the
`finishType` workaround and the body-param heuristics entirely.

## Result
- All previously-failing ARM specs compile: storage, security,
recoveryservicesbackup, quota, policyinsights, iothub,
cognitiveservices, botservice, apimanagement, frontdoor, databoxedge.
Overrides that genuinely dropped `@path` on a realized path param add
`@path` (correct); phantom cases (cognitiveservices
`calculateModelCapacity` `name`) need no spec change.
- `override.test.ts` 16/16; full TCGC suite 1330 pass.

---------

Co-authored-by: tadelesh <chenjieshi@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>